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The present invention generally relates to 
telecommunications networks and more particularly to 
methods and associated apparatus for transporting 
network management information between network 
3 5 elements. 
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2 . Description of the Related Art 

Network elements (also known as nodes) in a 
telecommunications network exchange network management 
5 information with one another using a common protocol . 
Common Management Information Service Element (CMISE) 
and Common Management Information Protocol (CMIP) , for 
example, are known protocols for transporting and 
processing network management information in 

10 Synchronous Optical Network (SONET) and SONET-derived 
networks such as Synchronous Digital Hierarchy (SDH) . 
CMISE and CMIP are based on Open System Interconnection 
(OSI) standards. Various manufacturers of SONET 
equipment have also implemented proprietary network 

15 management protocols. 

The use of network elements utilizing different 
network management protocols in the same network can 
lead to interoperability problems. Network management 

2 0 information exchanged between two network elements that 
use incompatible protocols can be misinterpreted, 
yielding unpredictable results. One way of solving the 
interoperability problem is to use a dedicated gateway 
or translation device between incompatible network 

25 elements. Using a gateway, however, increases the cost 
and complexity of the network. Thus, a simple and 
cost-effective technique for transporting network 
management information between incompatible network 
elements is highly desirable. 

30 

SUMMARY OF THE INVENTION 

The present invention relates to a method and 
associated apparatus for transporting network 
35 management information through incompatible network 
elements (NEs) in a telecommunications network. In 
accordance with the invention, a first NE transports 
frames of information to a second NE, which is not 
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compatible with the first NE . The second NE relocates 
the network management information contained in a first 
set of byte locations of the frames received from the 
first NE to a second set of byte locations of frames 
5 destined for a third NE, which is compatible with the 
second NE. The third NE then relocates the network 
management information contained in the second set of 
byte locations of the frames received from the second 
NE to a first set of byte locations of the frames 

10 destined for a fourth NE, which is compatible with the 
first NE. The second set of byte locations of frames 
from the second NE and third NE can be thought of as a 
virtual tunnel which allows network management 
information to be transparently transported from the 

15 first NE to the fourth NE. The tunnel can be setup 
using a single NE or multiple compatible NEs . 

In one example, the frames transported between NEs 
are SONET frames; the first set and second set of byte 
20 locations are data communication channels in a SONET 
section overhead and a SONET line overhead, 
respectively. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 

FIG. 1 shows a pictorial representation of a 
conventional SONET frame. 

FIGS. 2A and 2B show a schematic diagram of SONET 
networks in one embodiment . 
30 FIG. 2C shows a pictorial representation of the 

transportation of network management information 
through a tunnel in the network shown in FIG. 2A. 

FIG. 3A shows a schematic diagram of relevant 
portions of a network element in one embodiment. 
35 FIG. 3B shows a pictorial representation of a time 

division multiplex (TDM) data in one of the data paths 
used in the network element shown in FIG. 3A. 
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FIG. 3C shows a schematic diagram of a TDM cross- 
connect apparatus in one embodiment . 

FIG. 3D shows further details of the TDM cross- 
connect apparatus shown in FIG. 3C. 

5 

The use of the same reference numeral in different 
figures indicates the same or similar element. 

DETAILED DESCRIPTION 

10 

SONET networks, in general, are well known and are 
described in the American National Standards Institute 
("ANSI") documents ANSI T1.105, ANSI Tl. 105.01, ANSI 

_ Tl.105.02, ANSI Tl.105.03, ANSI Tl.105.04, ANSI 

g5 15 Tl.105.05, ANSI Tl.105.06, ANSI Tl. 105.07, ANSI 

Tl.105.08, and ANSI Tl.105.09, all of which are 

L ~g available from ANSI (Internet web site "www.ansi.org") ; 

^3 see also, W. J. Goralski, M SONET : A guide to 

Synchronous Optical Networks," McGraw-Hill 1997. All 

s 2 0 of the aforementioned SONET documents are incorporated 

jf* herein by reference in their entirety. 

Q In FIG. 1, a conventional SONET frame 10 (e.g., 

f» STS-1) is pictorially shown as an array of byte 

25 locations having 9 rows and 90 columns. SONET frame 10 
is divided into four sections namely section overhead 
20, line overhead 30, path overhead 41, and user data 
42. Section overhead 20, line overhead 30, and path 
overhead 41 carry operational, administration, 

3 0 maintenance, and provisioning (OAM&P) information while 
user data 42 carry the data to be transported. Path 
overhead 41 and user data 42 compose a synchronous 
payload envelope (SPE) 40. 

3 5 The byte locations composing section overhead 2 0 

are in rows 1 to 3 , columns 1 to 3 (i.e., bytes Al , A2 , 
CI, B1,...D2, and D3) of SONET frame 10. Byte 
locations Dl, D2 , and D3 of section overhead 20, 
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collectively denoted in FIG. 1 as "SDCC 21", are 
commonly known as section data communications channel 
(SDCC) bytes. Typically, SDCC 21 is used by network 
elements to carry network management information in 
5 accordance with a network management protocol 

(hereinafter "protocol") . The use of incompatible 
protocols by different equipment manufacturers, 
however, has created interoperability problems. For 
instance, a network element using an OSI -based protocol 
10 will not be able to read network management information 
from a network element using a Transport Control 
Protocol/Internet Protocol (TCP/IP) based protocol. 
Worst, network management information from an 

f ^ incompatible network element can get misinterpreted and 

y3 15 thereby yield unpredictable results. 

ry 

In the present invention, a virtual tunnel is 
2* created through compatible network elements to allow 

[S network management information from an incompatible 

5 2 0 network element to transparently pass through the 

[~ tunnel. FIG. 2A shows a schematic diagram of a SONET 

U network 2 00 in one embodiment of the invention. In 

™ network 200, network elements (NEs) 220 and 221 use an 

q OSI -based protocol while NEs 211, 212, and 213 use a 

25 TCP/IP-based protocol. A tunnel is created through NEs 
211, 212, and 213 to allow network management 
information from NE 220 to reach NE 221 without getting 
processed, and misinterpreted, by NEs 211, 212, and 
213. In one embodiment, the tunnel is created by first 
3 0 relocating the network management information in SDCC 
21 of SONET frames received by NE 211 from NE 22 0 into 
another group of byte locations of SONET frames 
destined for NE 212. As shown in FIG. 1, the byte 
locations composing line overhead 3 0 are in rows 4 to 
35 9, columns 1 to 3 (i.e., byte locations HI, H2 , H3 , 

B2,...Z2, and E2) of SONET frame 10. Byte locations D4 
to D12, also known as line data communications channels 
(LDCCs) , are not defined in existing SONET standards. 
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Thus, byte locations D4 , D5, and D6, collectively 
denoted as LDCC 31, can be used to carry the contents 
of SDCC 21 of NE 220 (hereinafter * foreign SDCC" ) . In 
NE 211, the foreign SDCC is relocated from SDCC 31 of 
5 SONET frames received from NE 22 0 to LDCC 31 of SONET 
frames destined for NE 212. NE 211 also moves its own 
network management information into the SDCC 21 of 
SONET frames destined for NE 212. Because NE 212 is 
compatible with NE 211, NE 212 processes the SDCC 21 of 
10 SONET frames from NE 211. The foreign SDCC now located 
in LDCC 31 of SONET frames from NE 211 is simply copied 
over to the LDCC 31 of SONET frames destined for NE 
213. NE 212 moves its own network management 
m information into SDCC 21, if appropriate, for all 

yi 15 frames destined for NE 213. NE 213 is compatible with 

NE 212 and thus processes the received SDCC 21 without 
processing LDCC 31. Because NE 221 is compatible with 
NE 220, and not with NE 213, NE 213 relocates the 
foreign SDCC from LDCC 31 back to SDCC 31 for all SONET 
20 frames destined for NE 221. The LDCC 31 of SONET 

frames transported from NE 211 to NE 213 can be thought 
of as a virtual tunnel which allows incompatible 
network management information, such as foreign SDCCs, 
to transparently pass through. The above technique can 

2 5 also be used to transmit network management information 
from NE 221 to NE 220. Other undefined byte locations 
of a SONET frame can also be used as a tunnel including 
LDCC 32 (byte locations D7 , D8 , and D9) and LDCC 33 
(byte locations D10, Dll, and D12) . In the prior art, 

3 0 information carried in the section overhead and line 
overhead of a SONET frame is only relevant to a 
receiving network element and is thus consumed at that 
network element. In the present invention, information 
in the section overhead and line overhead can be passed 

35 to another network element as part of a virtual tunnel. 

FIG. 2C pictorially illustrates the transportation 
of OSI-based network management information 260 (NMI 
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260) through a tunnel between NE 211 and NE 213. As 
shown in FIG. 2C, SONET frames 10 from NE 220 to NE 211 
carry NMI 260 in section overhead 20 (e.g., in SDCC 
21) . SONET frames 10 from NE 211 to NE 212 carry NMI 
5 260 in line overhead 30 (e.g., in LDCC 31) and TCP/IP- 
based network management information 27 0 (NMI 2 70) in 
section overhead 20. SONET frames 10 from NE 212 to NE 
213 carry NMI 260 in line overhead 3 0 and NMI 270 in 
section overhead 20. SONET frames 10 from NE 213 to NE 
10 221 carry NMI 260 back in section overhead 20. Thus, 
NMI 260 is transported from NE 220 to NE 221 without 
being processed in NE 211, NE 212, and NE 213. 

An algorithm for the above described tunneling 
15 technique can be summarized as follows: 

• For all SONET frames received from an 
incompatible network element and destined for a 
compatible network element: (a) transfer the 
contents of SDCC 21 to LDCC 31 and (b) use SDCC 

2 0 21 to carry compatible network management 

information . 

• For all SONET frames received from a compatible 
network element and destined for a compatible 
network element: (a) process the contents of 

25 SDCC 21, (b) update SDCC 21 if appropriate, and 

(c) do not process LDCC 31. 

• For all SONET frames received from a compatible 
network element and destined for an incompatible 
network element: (a) process the contents of 

3 0 SDCC 21 and (b) transfer the contents of LDCC 31 

to SDCC 21. 

• For all SONET frames received from an 
incompatible network element and destined for an 
incompatible network element: (a) do not process 

35 SDCC 21 and (b) do not process LDCC 31. 

In one embodiment, the tunnel is configured 
manually by a human operator who, by inspection, knows 
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the topology of the network and which network elements 
are not compatible. In provisioning communications 
lines (also known as "circuits") in SONET network 200, 
for example, the operator can indicate in the 
5 provisioning software that: 

(a) in NE 211: an incoming SDCC 21 from NE 220 is 
to.be relocated to an LDCC 31 destined for NE 212, 
an incoming LDCC 31 from NE 212 is to be relocated 
to an SDCC 21 destined for NE 220; 
10 (b) in NE 212: an incoming LDCC 31 from NE 211 is 

to be passed to an LDCC 31 destined for NE 213, an 
incoming LDCC 31 from NE 213 is to be passed to an 
LDCC 31 destined for NE 211; 

(c) in NE 213: an incoming LDCC 31 from NE 212 is 
=3 15 to be relocated to an SDCC 21 destined for NE 221, 

y, an incoming SDCC 21 from NE 221 is to be relocated 

to an LDCC 31 destined for NE 212. 
fl Techniques for provisioning communications lines in 

p2 SONET networks are well known. 

I 20 

The tunneling technique of the present invention 
Lu can be used in a variety of network topologies. FIG. 

2B shows a schematic diagram of a SONET network 250 in 
one embodiment of the invention. In network 250, NEs 
25 230-233 use one protocol to transport and process 

network management information while NEs 240-243 use a 
different protocol. To prevent interoperability 
problems arising from the use of different protocols, a 
tunnel is created between NEs 240 and 241, between NEs 
3 0 241 and 242, between NEs 242 and 243, and between NEs 

243 and 240 (a total of 4 tunnels in network 250) . For 
example, network 250 can be provisioned as follows. 
Tunnel Between NE 24 0 and NE 241 

(a) In NE 240: an SDCC 21 from NE 230 is to be 
35 relocated to an LDCC 31 destined for NE 241, an 

LDCC 31 from NE 241 is to be relocated to an SDCC 
21 destined for NE 230. 



-8- 



□ 



(b) In NE 241: an SDCC 21 from NE 231 is to be 
relocated to an LDCC 31 destined for NE 24 0, an 
LDCC 31 from NE 24 0 is to be relocated to an SDCC 
21 destined for NE 231. 
5 Tunnel Between NE 241 and NE 242 

(a) In NE 241: an SDCC 21 from NE 231 is to be 
relocated to an LDCC 31 destined for NE 242, an 
LDCC 31 from NE 242 is to be relocated to an SDCC 
21 destined for NE 231. 

10 (b) In NE 242: an SDCC 21 from NE 232 is to be 

relocated to an LDCC 31 destined for NE 241, an 
LDCC 31 from NE 241 is to be relocated to an SDCC 
21 destined for NE 232. 
Tunnel Between NE 242 and NE 243 

15 (a) In NE 242: an SDCC 21 from NE 232 is to be 



relocated to an LDCC 31 destined for NE 243, an 
LDCC 31 from NE 243 is to be relocated to an SDCC 
21 destined for NE 232. 

(b) In NE 243: an SDCC 21 from NE 233 is to be 
20 relocated to an LDCC 31 destined for NE 242, an 

LDCC 31 from NE 242 is to be relocated to an SDCC 
21 destined for NE 233. 
3 Tunnel Between NE 243 and NE 24 0 



(a) In NE 243: an SDCC 21 from NE 233 is to be 
25 relocated to an LDCC 31 destined for NE 240, an 

LDCC 31 from NE 24 0 is to be relocated to an SDCC 
21 destined for NE 233. 

(b) In NE 240: an SDCC 21 from NE 230 is to be 
relocated to an LDCC 31 destined for NE 243, an 

3 0 LDCC 31 from NE 24 3 is to be relocated to an SDCC 

21 destined for NE 230. 
The use of tunnels in network 250 allows NEs 230-233 to 
exchange network management information without 
disrupting the exchange of network management 

35 information among NEs 240-243. 

FIG. 3A shows a schematic diagram of a network 
element 3 00 (NE 3 00) in one embodiment of the 
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invention. Components that are well known and not 
necessary to the understanding of the invention have 
been omitted in the interest of clarity. NE 300 can be 
used, for example, in place of NEs 211-213 in SONET 
5 network 2 00 or in place of NEs 240-243 in SONET network 
250. NE 300 includes multiple port cards 320 and 321 
(also known as trunk/drop cards) for receiving and 
transmitting SONET frames 10. Each of port cards 320 
and 321 has multiple ports which are also known as line 
10 interfaces. Incoming SONET frames 10 received by a 
port in port cards 32 0 are sent to a Timing, 
Communication, and Control (TCC) processor 312 over a 
System Communications Link (SCL) bus 370. While there 
are multiple SCL buses in NE 300, one for each port, 

Q 

y3 15 only SCL bus 370 and 371 are shown for clarity. In one 

ji example, each SCL bus is a time division multiplexed 

%a (TDM) bus synchronized at 16Mbits/s (i.e., 16 Mega-Bits 

y3 per second) . Time division multiplexing, in general, 

n 

?* is well known. FIG. 3B shows a pictorial 

s 2 0 representation of the information carried in an SCL 

bus. Each SCL bus is divided into four 4Mbits/s 
logical buses, which are BUS0, BUS1, BUS 2 , and BUS 3 . 
O Each logical bus has 64 time slots (TS0, TS1,...TS63) 

ZZ t and is frame -aligned using an 8KHz framing clock. That 

25 is, a TS0 (or TS1 or TS2 . . . ) arrives every 125|is. Each 
time slot consists of a byte (8 bits) of data and can 
be bit-interleaved. Thus, each logical bus is 
essentially a Digital Signal-0 (DS-0) channel. 

3 0 In one example, SDCC 21, LDCC 31, LDCC 32, and 

LDCC 3 3 are mapped in logical BUS0 of SCL bus 3 70 as 
follows : 

MAPPING IN LOGICAL BUSO 
TS16 - Contains Byte Dl of SDCC 21 
35 TS20 - Contains Byte D2 of SDCC 21 

TS24 - Contains Byte D3 of SDCC 21 
TS28 - Contains Byte D4 of LDCC 31 
TS32 - Contains Byte D5 of LDCC 31 
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TS36 - Contains Byte D6 of LDCC 31 

TS40 - Contains Byte D7 of LDCC 32 

TS44 - Contains Byte D8 of LDCC 32 

TS48 - Contains Byte D9 of LDCC 32 

5 TS52 - Contains Byte D10 of LDCC 33 

TS56 - Contains Byte Dll of LDCC 33 

TS60 - Contains Byte D12 of LDCC 33 
Other time slots in logical buses BUSO, BUS1, BUS 2 , and 

BUS3 carry other types of information such as messages 

10 between cards (e.g., card status), alarms, and other 
bytes of a SONET frame . 

Referring back to FIG. 3A, time slots in SCL bus 
„ 3 70 are received by a message router 33 0 and a time 

y3 15 division multiplex cross-connect 340 (TDMXConn 340) . 

2/j Message router 33 0 extracts and routes messages carried 

11 in logical BUS 2 of SCL 370. TDMXConn 340 receives time 

^3 slots from SCL bus 370 on terminal TDM IN 3 8 OA and 

tt relocates (i.e., cross-connects) the time slots to any 

s 20 time slot of any logical bus of any SCL bus. TDMXConn 

340 is essentially a DS-0 cross-connect. For example, 
TDMXConn 340 can relocate the contents of TS16, TS20, 
and TS24 (i.e., SDCC 21) of logical BUSO of SCL bus 370 
to TS28, TS32, and TS36 (i.e., LDCC 31), respectively, 
25 of logical BUSO of SCL bus 371, thereby creating a 
tunnel through NE 300. Terminal MSG IN 380B of 
TDMXConn 34 0 receives the messages processed by message 
router 330 for insertion into a time slot of SCL bus 
371. The output of TDMXConn 340 comes out of a 
30 terminal TDM 380C and is transmitted onto SCL bus 371 
through drivers 342 . A control vector random access 
memory 341 (CtlVec RAM 341) controls the cross- 
connection of time slots in TDXConn 340. 

35 FIG. 3C shows a schematic diagram of TDMXConn 340. 

TDMXConn 340 uses a well known TDM cross-connect 
technique known as Sequential -Write/Random-Read . In 
this technique, incoming time slots are written into an 



l s f 
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input buffer in the order the time slots are received 
(sequential write) . The time slots are then read in 
any order (random read) for insertion into any outgoing 
time slots. Referring to FIG. 3C, TDMXConn 340 has 
5 multiple TDM processors (TDM processors 380D, 

381D # . . . ) , one for each port, for cross-connecting the 
time slots of multiple SCL buses. TDM processor 380D 
reads a time slot from any of the input buffer 
RAMs (e.g. , input buffer 342A) and multiplexes the time 
10 slot with another time slot (e.g., another time slot 
from input buffer 34 2B) using MUX 343 for output to 
outgoing time slots of SCL bus 371 (see FIG. 3A) on 
terminal TDM OUT 380C. Similarly, TDM processor 381D 
^ reads a time slot from any input buffer RAM, 

yg 15 multiplexes the time slot with another time slot from 

^ the same or different input buffer RAM, and then 

outputs the time slot and the other time slot as time 

'J3 slots on an SCL bus on terminal TDM OUT 3 81C. 

O 
i n 

20 FIG. 3D shows further details of TDMXConn 340 in 

one embodiment of the invention. TDMXConn 34 0 is 
hi synchronized with the 16Mbits/s clock of the SCL buses. 

O Incoming time slots on terminal TDM IN 380A are 

'Pi reclocked at input flip-flop 344A (IFF 344A) and then 

25 shifted into a serial to parallel register 346A (SP 
34 6A) . Whenever an 8 -bit time slot data becomes 
available in SP 346A, that time slot data is written 
into input buffer 342A, which can be a 16Kx8 dual port 
RAM. In one embodiment, a time slot from SP 34 6A is 
30 written into input buffer 342A once for every 128 clock 
cycles of the 16Mbits/s clock. The next 127 clock 
cycles of the 16Mbits/s clock are then used for reading 
time slots from the input buffers (input buffers 342A, 
342B, . . .) . Time slots read from input buffer 342A are 
35 first buffered in a flip-flop 347A (FF 347A) before 

being presented at the input of a data multiplexer 343 
(D-MUX 343) . D-MUX 343, which can be a multi-stage 
pipelined multiplexer, multiplexes the time slots 
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received from any of the input buffers for output into 
any of the outgoing time slots on any of the output 
terminals (i.e., TDM OUTs 380C, 381C,...). For 
example, a time slot read from input buffer 342A can be 
written into FF 348A through D-MUX 343. The time slot 
in FF 348A is written into a parallel to serial 
register 349A (PS 34 9A) and then serially read out to 
an input of an output multiplexer 350A (O-MUX 350A) . 
O-MUX 3 50A multiplexes the time slot from input buffer 
342A with a time slot from message router 33 0, received 
on terminal MSG IN 3 8 OB, for output onto the outgoing 
time slots on terminal TDM OUT 380C via flip-flop 351A 
(FF 351A) . 

In one example, CtlVec RAM 341 is implemented 
using a 16Kxl6 RAM. The addresses of CtlVec RAM 341 
contain vectors for selecting a specific port, logical 
bus, and time slot written on any of the input buffers. 
A vector points to the input buffer address which 
contains a selected time slot of a logical bus of a 
particular port. Table 1 shows the contents of CtlVec 
RAM 341 in one example. 



Table 1 



Address 


Contents 


Usage 


0 


PORTO, BUS 0,TS0 


Control vector for port 0, 
logical BUSO, time slot TSO 


1 


PORTO, BUS 0,TS1 


Control vector for port 0, 
logical BUSO, time slot TS1 








63 


PORT0,BUS0>TS63 


Control vector for port 0, 
logical BUSO, time slot TS63 


64 


PORTO, BUS 1,TS0 


Control vector for port 0, 
logical BUS1, time slot TSO 








256 


PORTl,BUS0,TS0 


Control vector for port 1, 
logical BUSO, time slot TSO 
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16384 


PORTm, BUSn, Tsy 


Control vector for port m, 
logical BUSn, time slot TSy 



In Table 1, port 0 refers to a port in port cards 320 
whose SCL bus is connected to terminal TDM IN 3 8 OA 
(similarly, port 1 refers to a port in port cards 320 
whose SCL bus is connected to terminal TDM IN 3 81A 
etc.) . The format of the 16-bit contents of CtlVec RAM 
341 in one example is shown in Table 2. 



Table 2 



C3 



in 



£3 

a 



10 



15 



20 



Bit 


Usage When Bit 14 
is a "0" 


Usage When Bit 14 
is a "1" 


15 


Not Used 


Not Used 


14 


0 


1 


13-8 


Selected Port 


Not used 


7-6 


Selected Logical 
Bus 


Transmit Byte 


5-0 


Selected Time 
slot 



As shown in Table 2, when bit 14 of CtlVec RAM 341 is a 
"0," bits 13-8, 7-6, and 5-0 indicate the selected 
port, selected logical bus, and selected time slot, 
respectively, to be read out of an input buffer. When 
bit 14 is a "1," the bits of CtlVec RAM 341 do not 
represent a vector for reading a time slot from an 
input buffer. Rather, bits 7-6 contain a transmit data 
byte which will be inserted into a next outgoing time 
slot. Thus, besides the cability to cross-connect time 
slots, TDMXConn 340 can also insert a programmed byte 
into an outgoing time slot. Bit 15 of CtlVec RAM 341 
is not used in this particular example. 



25 CtlVec RAM 341 and counter 354 (cntl6 354) form a 

microprogrammed algorithmic state machine. Cntl6 354 
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sequences the reading of vectors from CtlVec RAM 341 
and provides control information for writing a time 
slot on any of the input buffers. Vectors from CtlVec 
RAM 341 and control information from cntl6 354 are 
5 presented at the input buffers through an address 

multiplexer 352 (A-MUX 352) . A vector presented at an 
input buffer is also used, at the same time, to select 
an input on D-MUX 343 such that the time slot read from 
the input buffer is sent to the appropriate outgoing 

10 time slot- Note that because the time slots are time 

division multiplexed on a synchronous bus, the contents 
of an incoming time slot can be relocated to an 
outgoing time slot by using the vectors from CtlVec RAM 
341 to read the incoming time slot out of an input 

15 buffer and through D-MUX 343 at the appropriate time. 

For example, the contents of an incoming time slot TS16 
of logical bus 0 of the port connected to terminal TDM 
IN 380A can be relocated to an outgoing time slot TS28 
of logical BUSO of the port connected to terminal TDM 

2 0 OUT 3 81C by reading the incoming time slot TS16 out of 

input buffer 342A at the time outgoing time slot TS2 8 
is next available for output on terminal TDM OUT 381C. 

Vectors are conventionally downloaded to CtlVec 
25 RAM 341 after a provisioning change to reflect the 

cross-connections of the time slots. For example, the 
vectors can be downloaded after the user has 
provisioned to relocate the SDCCs 21 of a port 
connected to terminal TDM IN 3 8 OA to LDCCs 31 of 

3 0 another port connected to terminal TDM OUT 3 81C to 

create a tunnel. Of course, the vectors can also be 
changed and downloaded to CtlVec RAM 341 to reflect 
SONET protection switching. 

35 While the invention is described using SDCC 21 and 

LDCC 31 as an example, the invention is not so limited 
and may use other byte locations in a SONET frame. 
Further, the invention is not limited to SONET networks 
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as any telecommunications network may benefit from the 
disclosed tunneling technique. The invention is set 
forth in the following claims. 



Ln 
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